X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C92FD6.D827E3E8@onstor-exch02.onstor.net>; Thu, 16 Oct 2008 14:33:35 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: RE: Functional Spec for Restarting Aborted Mirror Sessions
Date: Thu, 16 Oct 2008 14:33:34 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E0C0D8788@onstor-exch02.onstor.net>
In-Reply-To: <20081016141951.2a5de00c@ripper.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Functional Spec for Restarting Aborted Mirror Sessions
Thread-Index: Ackv1O3tEhWUVqkHQgKyrh7qzDZeLwAAYdLQ
References: <BB375AF679D4A34E9CA8DFA650E2B04E0C0D86BA@onstor-exch02.onstor.net><BB375AF679D4A34E9CA8DFA650E2B04E0C0D8733@onstor-exch02.onstor.net><BB375AF679D4A34E9CA8DFA650E2B04E0C0D8754@onstor-exch02.onstor.net> <20081016141951.2a5de00c@ripper.onstor.net>
From: "Amit Bothra" <amit.bothra@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>,
	"Deepak Veliath" <deepak.veliath@onstor.com>
Cc: "dl-Design Review" <dl-designreview@onstor.com>

I agree. I plan to schedule the review coming Tuesday. But I would still
request folks to continue sending their review comments thru email so
that we have some common ground before getting together for the review
meeting.

Thanks,
Amit



-----Original Message-----
From: Andy Sharp=20
Sent: Thursday, October 16, 2008 2:20 PM
To: Deepak Veliath
Cc: dl-Design Review
Subject: Re: Functional Spec for Restarting Aborted Mirror Sessions

This one is complicated enough that I think we should schedule a
meeting to discuss.  Anyone disagree?

On Thu, 16 Oct 2008 14:04:35 -0700 "Deepak Veliath"
<deepak.veliath@onstor.com> wrote:

> Hello Jonathan,
> 1.	Section 5, as you make clear, the key to restarting is to
> know what the target has on disk, basically a checkpoint marker.
> Since we send blocks in order can we just periodically write out the
> last block number know to have hit disk?  A super-block field would
> be easy.  While an implementation note, this would avoid changing the
> cluster DB and that is relevant here.  When all the blocks have been
> received we can just set the number to the last block number in the
> file system so it handles a lot of the cases you have mentioned.
>=20
> We issue I/Os to read the blocks on the source in order.  But there
> seems to be no guarantee the I/Os finish and return in that order.  We
> send out blocks to the target as soon as they have been read.  On the
> target again the I/O is issued as they come in over the RMC connection
> but there seems to be no guarantee of ordering.  I realize our current
> IO scheduler might guarantee some sort of ordering, but this could
> change in the future.  The mirroring sub-system shouldn't expect it
> works a certain way unless the IO scheduler exports a mechanism to
> guarantee this ordering.
>    =20
> 2.	Section 6, I'm not sure that the restart command adds a lot,
> avoiding the creation of a new snapshot is the only clear addition
> over mirror start and that doesn't seem worth creating a new command
> verb.
>=20
> Since creating a new snapshot consumes some amount of space (and will
> mean space can be allocated as the FS is modified), I felt a "restart"
> only command would allow a previously aborted mirror to run through to
> completion without potentially consuming space in the FS.
> =20
> 3.	Section 6, mirror start MIRRORNAME [skiprestart] To date we
> have not used whole words for command options in the shell, but
> instead use things like -a, -b, etc.  Other than testing, why would a
> customer ever want to skip a restart?  While a large transfer can
> happen at any point, the real problem here is baseline transfers so
> if the target is garbage in some way we can just start over by
> detecting that, rather than having the administrator try to figure it
> out.  This also reduces the test cases and the need to change the GUI
> or the CLI.=20
>=20
> I see a lot of "force" options in the existing mirroring commands --
> they were the basis for this choice.  I'll change it to "-s".  As to
> the need for such an option, I felt a mechanism to bypass the whole
> restart logic and being able to fall-back on to the traditional logic
> might be desired by an administrator.  The baseline transfer has
> nothing to do with this option and can be completed successfully with
> or without this option.
>=20
> Thank you,
> veliath
> =20
>=20
> =20
>=20
> =20
>=20
> ________________________________
>=20
> From: Deepak Veliath=20
> Sent: Thursday, October 16, 2008 12:03 PM
> To: dl-Design Review
> Subject: Functional Spec for Restarting Aborted Mirror Sessions
>=20
> =20
>=20
> \\mightydog\software\Kegg\Functional
> Specs\RestartAbortedMirrorSessionsFuncSpec.doc
>
<file:///\\mightydog\software\Kegg\Functional%20Specs\RestartAbortedMirr
> orSessionsFuncSpec.doc>=20
>=20
